ER model 為大部分的後端專案在開發前會先規劃的一個文件， 尤其在開發API的時候， 很常都是在對資料庫做操作， 如果一開始的資料表規劃沒有規劃清楚， 很有可能造成API的結果不符合預期。

1**. ER模型的主要目的：**

• 確認實體及關係：

  ER model 提供了一種統一的方式來描述角色和角色之間的關係, 使整個實體結構化和有組織。

  這裡我針對數據結構構化及實體關係做個簡單介紹：

1.1 數據結構化：

• 定義：ER模型為數據和其間的關係提供了一個標準化的表達方式, 就是用表格來描述我們現實的實體。
• 好處：通過結構化數據，開發者可以更加清楚地看到專案中所涉及的所有數據元素，以及它們之間的互動和依賴。

1.2 確認實體及關係：

• 定義：ER模型強調了實體（數據項目，如用戶或訂單）及其間的關係（例如用戶和訂單之間的關聯）。
• 關係：這裡個關係主要有：一對一、一對多、多對多，
  • 以我專案的例子假設我pokemon的名稱不可以重複,那他就是一對一關係。
  • 每一隻pokemon只有一個性格，但每種性格可以被多個寶可夢擁有，那就是一對多。
  • 每一隻pokemon可以有多個技能(1-4)，而每個技能都可以被多個pokemon擁有，這就是多對多。
• 好處：這有助於開發者在專案開始前就清晰地了解所有角色及其間的交互方式，從而減少日後修改和重構的需要。

2. 我的ER-model

以下是我實際的圖

• 我主要有pokemons、natures、abilities、skills、races這幾個表單。
• 我pokemons的欄位主要都是存不同屬性的id， 因為我大部分的屬性值都是給使用者選項， 所以每個屬性我會有單獨一張表格，然後屬性資料的拿取我會用關聯的方式。

遇到的問題

• 我那時對於寶可夢的屬性(比如說natures、abilities…)是否可以用欄位去存，還是要存成表格有點疑問，因為我目前的這些屬性我就只有名稱，所以我做了一個比較：

  屬性存成表格vs直接用欄位去記

  1. 使用表格：

  好處：

  • 彈性、擴展性：如果未來想為性格或能力(在一個屬性值)添加更多的資訊或欄位，如影響因子、圖片等，使用表格將更有彈性，如果是用欄位儲存的話，可能你要在同一個欄位儲存多個值，或是新增欄位（但會影響的整張表的結構）。
  • 是否需要預先加載資料：比如我這裡nature的部分，我是有一些預先加載好的資料讓使用者可以選擇，如果有表格先存起來，我就可以去撈資料顯示給使用者看。

  2. 使用欄位：

  好處：

  • 簡單性：較少的表格和關聯，對於小型應用或快速原型設計可能較為合適，就是假如我今天對於nature這個屬性，我就是只有名稱而已，而且我是讓使用者可以自己輸入，那我覺得直接用欄位或許也可以。

  缺點：

  • 冗餘：如果有很多寶可夢使用相同的性格或能力，這些資訊會在 Pokemon 表格中重複。
  • 不夠彈性：修改或添加新的性格和能力可能需要直接修改資料庫結構或資料。

  3.小結論

  最後我選擇用表格的方式，考慮到整個專案之後的拓展，每個屬性還有可能再加入新的東西。

• 今天我還有一個情況是，我的寶可夢和技能是一個多對多關係，那我是要選擇在同一張表建立多個欄位(比如技能1、技能2…)，還是用陣列儲存在一個欄位，還是我要直接創多對多表格。

  以下我做了一個比較：

  用同一張表的多個欄位儲存 VS 陣列存屬性 VS 用表格建立多對多

  使用多個欄位儲存

  優點：

  1. 方便查詢：我覺得這個查詢應該是相對簡單的，相對於多對多表格我不用去join另一張表，相對於陣列儲存，我可以減少一些邏輯上的複雜度。

  缺點：

  1. 拓展性差: 如果我想要增加學習的技能，可能會造成需要新增欄位影響到整個表的結構。

  使用陣列儲存：

  優點：

  1. 單一查詢: 當讀取主要的資料表時，你可以同時取得所有技能，不需要進行附加的連接查詢。
  2. 拓展性: 相對於儲存成多個欄位，如果我今天想新增一個技能，就直接驗證條件修改一下就可以了。

  缺點：

  1. 非正規化: 技能的更新和維護可能會更加複雜。
  2. **查詢：**在查詢方面比如說今天你要查這個陣列裡面的其中一個值，你可能會很難查詢。
  3. 對於驗證或更新，可能會比較麻煩一些，畢竟還要對陣列做處理。

  使用多對多表：

  優點：

  1. 正規化: 技能的添加、刪除和更新會更加方便，且保證資料的一致性。
  2. 彈性查詢: 你可以更容易地查找具有特定技能的實體。
  3. 可擴展性: 如果未來需要儲存有關技能的更多信息，如描述、類型等，多對多關聯會更加方便。

  缺點：

  1. 查詢複雜性: 需要執行 JOIN 操作來獲得技能資料，這可能會使查詢變得稍微複雜。
  2. 效率: 雖然正確的索引和設計可以最大化效率，但不當的設計或缺乏索引可能導致效率問題。

  結論

  考慮到未來拓展性，我後來是採用在同一個pokemons表個儲存成陣列的方式。

3. 結語：

ER模型不僅為後端開發提供了一個穩固的基礎，而且能確保開發團隊在整個專案的生命週期中都有清晰的數據指引。正確的前期規劃可以減少後期的困惑和不必要的修改，從而提高專案的效率和質量。